5-1. 컨테이너 오케스트레이션 도구, 쿠버네티스 - 파트 1

5.1. 컨테이너 오케스트레이션

5.1.1. 오케스트레이션이란

컨테이너 기술에서 **오케스트레이션(Orchestration)**은 컨테이너의 관리 및 운영을 자동화하는 것을 나타냄. 실제로 컨테이너를 관리·운영할 때 공통적으로 필요한 작업은 크게 로드 밸런싱 / 헬스 체크 / 스케일링 세 가지임.

용어 정리

  • 오케스트레이션 (Orchestration): 다수의 컨테이너를 배치·감시·확장·복구하는 관리 운영 작업을 자동화하는 것

컨테이너 오케스트레이션의 3대 작업:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

                    [오케스트레이션]
                          │
        ┌─────────────────┼─────────────────┐
        ▼                 ▼                 ▼
  ┌───────────┐     ┌───────────┐     ┌───────────┐
  │ 로드 밸런싱 │     │  헬스 체크 │     │  스케일링  │
  └───────────┘     └───────────┘     └───────────┘
   요청을 분산해      정상 동작 여부를    요청 규모에 따라
   부하를 나눔        감시               컨테이너를 증감
        │                 │                 │
        └────── 결합 ──────┘                 │
        비정상 컨테이너로의 배분 중지          리소스 소비 최적화
        → 가동 시간(가용성) 증가              → 리소스 부족 다운 방지

5.1.2. 로드 밸런싱

계층별 로드 밸런싱 배치:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  요청
   │
   ▼
 [LB] ──┬──→ [웹 컨테이너 1]
        └──→ [웹 컨테이너 2]
                  │
                  ▼
                [LB] ──┬──→ [AP 컨테이너 1]
                       └──→ [AP 컨테이너 2]
                                 │
                                 ▼
                               [LB] ──┬──→ [DB 컨테이너 1]
                                      └──→ [DB 컨테이너 2]

5.1.3. 헬스 체크

5.1.4. 스케일링

5.1.5. 오케스트레이션의 중요성

작업 목적 대표 구현 방법 얻는 효과
로드 밸런싱 부하 분산 계층 앞에 로드 밸런싱 장치 배치 처리 시간 단축·처리량 증가
헬스 체크 정상 동작 감시 요청을 보내 응답 여부 확인 비정상 컨테이너 배제 → 가용성 향상
스케일링 규모 조절 메트릭 임곗값 기준 증감 리소스 최적화·리소스 부족 다운 방지

5.2. 쿠버네티스: 컨테이너의 관리 및 운영을 자동화하는 도구

5.2.1. 쿠버네티스란

5.2.2. 쿠버네티스에서 가능한 것

5.2.3. 쿠버네티스에서 불가능한 것

5.2.4. 컨테이너 오케스트레이션 도구의 사실상 표준

2026-10 갱신

  • 아파치 메소스는 Apache Attic으로 이관(프로젝트 은퇴)되어 더 이상 개발되지 않음. 마라톤 역시 사실상 개발 중단 → 현재 선택지로는 부적합
  • 원문의 "도커 데스크톱과 더불어 사실상 표준"은 오케스트레이션 도구가 아닌 도커 데스크톱을 같은 범주로 묶은 어색한 표현이므로, 도커 데스크톱은 쿠버네티스를 내장 제공한다는 의미로 정리

5.2.5. 쿠버네티스 클러스터란

5.2.6. 노드의 두 가지 유형

용어 정리

  • 쿠버네티스 클러스터 (Kubernetes Cluster): 쿠버네티스가 관리하는 서버(노드)들의 집합
  • 노드 (Node): 클러스터를 구성하는 각 서버
  • 마스터 노드 (Master Node): 워커를 제어하는 노드. 사용자의 요청 창구
  • 워커 노드 (Worker Node): 실제로 파드(컨테이너)를 구동하는 노드

2026-10 갱신

  • 쿠버네티스 공식 문서는 "마스터 노드" 대신 컨트롤 플레인(Control Plane) 이라는 용어를 사용함 (kube-apiserver·etcd·kube-scheduler·kube-controller-manager 등으로 구성). 노드 레이블·테인트도 node-role.kubernetes.io/master → node-role.kubernetes.io/control-plane으로 변경됨. 본 노트는 원서 표기를 유지

쿠버네티스 클러스터 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

    [사용자]
       │ 워커에 직접 실행하지 않고, 마스터를 통해 요청
       ▼
 ┌──────────────────┐
 │    마스터 노드     │  ← 워커를 제어 · 상태 감시
 └────────┬─────────┘
          │ 제어
   ┌──────┴────────────┬─────────────────┐
   ▼                   ▼                 ▼
┌────────────┐   ┌────────────┐   ┌────────────┐
│ 워커 노드 1 │   │ 워커 노드 2 │   │ 워커 노드 3 │
│ ┌────┐┌────┐│  │ ┌────┐     │   │ ┌────┐     │
│ │파드││파드││  │ │파드│     │   │ │파드│     │
│ └────┘└────┘│  │ └────┘     │   │ └────┘     │
└────────────┘   └────────────┘   └────────────┘
       └───────── 쿠버네티스 클러스터 ─────────┘

5.3. 파드: 컨테이너를 관리하는 단위

5.3.1. 파드란

용어 정리

  • 파드 (Pod): 쿠버네티스가 컨테이너를 관리하는 최소 단위. 스토리지·네트워크·라이프 사이클을 공유하는 하나 이상의 컨테이너 묶음

파드의 내부 구조:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌───────────────────────────────────────┐
 │                 파드                   │
 │  ┌────────────┐    ┌────────────┐     │
 │  │  컨테이너 A │    │  컨테이너 B │     │
 │  └─────┬──────┘    └──────┬─────┘     │
 │        └────── 공유 ───────┘          │
 │   · 네트워크 (localhost · 포트)         │
 │   · 스토리지 (볼륨)                     │
 │   · (설정 시) 프로세스 네임스페이스       │
 │   · 라이프 사이클 (동시 시작 / 동시 정지)  │
 └───────────────────────────────────────┘

5.3.2. 같은 파드에 포함할지 판단하는 기준

3계층 애플리케이션의 파드 구성:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[한 파드에 몰아넣기]                  [파드별로 분리 — 권장]
┌────────────────────┐              ┌──────┐ ┌──────┐ ┌──────┐
│        파드         │              │ 파드  │ │ 파드  │ │ 파드  │
│ ┌────┐┌────┐┌────┐ │              │┌────┐│ │┌────┐│ │┌────┐│
│ │ 웹  ││ AP ││ DB │ │              ││ 웹  ││ ││ AP ││ ││ DB ││
│ └────┘└────┘└────┘ │              │└────┘│ │└────┘│ │└────┘│
└────────────────────┘              └──────┘ └──────┘ └──────┘
 ✗ 필요한 것만 구동 불가                ✓ 필요한 컨테이너만 모아서 구동
 ✗ 스케일링이 뭉텅이로만 가능            ✓ 계층별로 세세하게 스케일링

5.3.3. 파드의 필요성

5.3.4. 파드의 디자인 패턴

one-container-per-pod vs 사이드카 패턴:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[기본형: one-container-per-pod]     [사이드카 패턴]
 ┌──────────────┐                  ┌────────────────────────────┐
 │      파드     │                  │            파드             │
 │ ┌──────────┐ │                  │ ┌──────────┐ ┌───────────┐ │
 │ │   기본    │ │                  │ │   기본    │ │  사이드카  │ │
 │ │  컨테이너  │ │                  │ │  컨테이너  │ │(예: Envoy)│ │
 │ └──────────┘ │                  │ └──────────┘ └───────────┘ │
 └──────────────┘                  │    기본 기능을 보조 · 확장     │
                                   └────────────────────────────┘

5.3.5. 사이드카 컨테이너를 사용하는 경우

용어 정리

  • 사이드카 컨테이너 (Sidecar Container): 기본 컨테이너의 기능을 보조·확장하기 위해 같은 파드에 함께 배치하는 컨테이너
  • Envoy: 파드 통신을 제어하는 프록시. 대표적인 사이드카 컨테이너 활용 사례
  • Istio: Envoy를 집중적으로 관리해 사이드카 배치를 자동화하는 소프트웨어

5.4. 디플로이먼트 컨트롤러: 오케스트레이션을 지원하는 가장 중요한 요소

5.4.1. 레플리카셋이란

5.4.2. 디플로이먼트란

쿠버네티스 리소스의 포함 관계:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌────────────────────────────────────────────────────┐
 │                    디플로이먼트                      │
 │  ┌─────────────────────┐  ┌─────────────────────┐  │
 │  │   레플리카셋 v1       │  │   레플리카셋 v2      │  │
 │  │  ┌──────┐ ┌──────┐  │  │  ┌──────┐           │  │
 │  │  │ 파드  │ │ 파드  │  │  │  │ 파드  │           │  │
 │  │  │┌────┐│ │┌────┐│  │  │  │┌────┐│           │  │
 │  │  ││컨테││ ││컨테││  │  │  ││컨테││           │  │
 │  │  ││이너││ ││이너││  │  │  ││이너││           │  │
 │  │  │└────┘│ │└────┘│  │  │  │└────┘│           │  │
 │  │  └──────┘ └──────┘  │  │  └──────┘           │  │
 │  └─────────────────────┘  └─────────────────────┘  │
 │       파드 수 점진 감소  ←→  파드 수 점진 증가        │
 │                  (롤링 업데이트)                     │
 └────────────────────────────────────────────────────┘

5.4.3. 컨트롤러란

컨트롤러의 조정 루프 (현재 상태 → 설정한 상태):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [설정한 상태]              [현재 상태]
    파드 3개        ←비교→     파드 2개
        │                       │
        └──────────┬────────────┘
                   ▼
          차이 발생 → 동작 결정 → 동작 실행
                   │                 │
                   ▼                 ▼
             "파드 1개 부족"     파드 1개 추가 생성
                   │                 │
                   └──── 차이 0 ◀────┘

 (에어컨 = 설정 온도와 실내 온도의 차이를 0으로 만드는 것과 동일한 원리)

5.4.4. 디플로이먼트 컨트롤러란

용어 정리

  • 레플리카셋 (ReplicaSet): 같은 유형의 파드를 지정한 수만큼 유지하는 관리 단위
  • 디플로이먼트 (Deployment): 레플리카셋을 그룹화·관리하며, 레플리카셋과 파드의 갱신을 자동화하는 단위
  • 컨트롤러 (Controller): 현재 상태를 설정한 상태로 맞추는 메커니즘
  • 롤링 업데이트 (Rolling Update): 구버전 파드를 점진적으로 줄이고 신버전 파드를 점진적으로 늘려 교체하는 방식

5.5. 서비스: 컨테이너에 접속하는 창구

5.5.1. 서비스란

5.5.2. 서비스의 구조

서비스의 작동 방식 (가상 IP + 네트워크 주소 변환):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  [클라이언트]
       │ 접속: 10.240.0.100 (엔드포인트 = 가상 IP 주소)
       ▼
 ┌──────────────────────────┐
 │          서비스           │
 │   네트워크 주소 변환(NAT)  │
 └────────────┬─────────────┘
    ┌─────────┼─────────────┬──────────────┐
    ▼         ▼             ▼              ▼
┌────────────┐      ┌────────────┐  ┌────────────┐
│   파드 A    │      │   파드 B    │  │   파드 C    │
│10.240.0.101│      │10.240.0.102│  │10.240.0.103│
└────────────┘      └────────────┘  └────────────┘
  → 변환 결과에 따라 어느 파드로든 전환 가능 (= 로드 밸런싱)

5.5.3. 서비스 유형

엔드포인트를 제공하는 방법의 차이에 따라 서비스는 네 가지 유형으로 분류됨.

유형 설명 클러스터 외부 접속
ClusterIP 클러스터 내부에서만 접속할 수 있는 가상 IP 주소가 생성됨 ✗
NodePort 클러스터의 모든 노드의 지정된 포트에 대한 접속이 컨테이너로 전달됨 ○
LoadBalancer 클라우드 서비스의 로드 밸런서에 대한 접속이 컨테이너로 전송됨 ○
ExternalName 서비스에 대한 접속이 지정된 호스트로 전달됨 (외부 호스트로 전환)

5.5.4. 서비스에 의한 로드 밸런싱

5.5.5. 각 서비스의 구분

상황 권장 유형 이유
클러스터 내부 접속만 필요 ClusterIP 노드 포트를 소비하지 않아 포트를 절약할 수 있음
클러스터 외부에서 접속 LoadBalancer 접속을 단일 엔드포인트로 집약할 수 있음
내부 동작 확인·자체 LB 구성 등 예외 NodePort 모든 노드의 지정 포트로 직접 접속 가능
클러스터 외부 호스트로 전환 ExternalName 내부에서 접속하되 대상은 외부 호스트
용어 정리

  • 서비스 (Service): 컨테이너 접속 창구인 엔드포인트를 제공하고 로드 밸런싱을 수행하는 쿠버네티스의 방식
  • 엔드포인트 (Endpoint): 컨테이너에 간접적으로 접속하기 위한 창구(가상 IP 주소 등)
  • 네트워크 주소 변환 (NAT): 패킷의 IP 주소를 다른 주소로 바꿔 전달하는 기술
  • Discovery & LB: 이름 확인과 로드 밸런싱 문제를 해결하는 쿠버네티스 리소스 유형

5.6. 플라넬: 컨테이너 간 상호 접속을 지원하는 기술

5.6.1. 파드 내 통신

5.6.2. 파드 간 통신

파드 내 통신 vs 파드 간 통신:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[파드 내 통신]                       [파드 간 통신]
 ┌─────────────────────────┐        ┌──────────┐        ┌──────────┐
 │           파드           │        │  파드 A   │        │  파드 B   │
 │ ┌─────────┐┌──────────┐ │        │10.244.1.5│ ─────→ │10.244.2.7│
 │ │ 웹 클라이 ││  웹 서버  │ │        └──────────┘   IP   └──────────┘
 │ │  언트    ││  :3000   │ │          (노드 1)    주소만    (노드 2)
 │ └────┬────┘└─────▲────┘ │
 │      └─ localhost ┘     │        → 파드마다 고유 IP → 포트 지정 불필요
 │  네트워크 네임스페이스 공유  │        → 노드의 포트 수 제한과 무관
 │  ※ 포트 충돌하지 않게 조정  │
 └─────────────────────────┘

5.6.3. 플라넬이란

5.6.4. flanneld란

플라넬의 오버레이 네트워크:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

 ┌────────────────────────┐        ┌────────────────────────┐
 │         노드 1          │        │         노드 2          │
 │  서브넷 10.244.1.0/24   │        │  서브넷 10.244.2.0/24   │
 │  ┌──────┐  ┌──────┐    │        │  ┌──────┐              │
 │  │ 파드  │  │ 파드  │    │        │  │ 파드  │              │
 │  └──────┘  └──────┘    │        │  └──────┘              │
 │      [ flanneld ]      │        │      [ flanneld ]      │
 └───────────┬────────────┘        └───────────┬────────────┘
             └─────── 오버레이 네트워크(IPv4) ────┘
                            │
                            ▼
                       [  etcd  ]  ← 네트워크 구성 · 할당 서브넷 정보 저장

 flanneld: 목적지 파드가 있는 컴퓨터를 특정해 패킷 전송 / 노드별 고유 서브넷 할당

5.6.5. 플라넬과 서비스의 차이

구분 플라넬 (Flannel) 서비스 (Service)
역할 노드를 넘나드는 파드 간 통신 경로 제공 컨테이너 접속 창구(엔드포인트) 제공
위치 기반 기술 (오버레이 네트워크) 상위 추상화 (Discovery & LB)
구현 수단 flanneld 에이전트 + IPv4 오버레이 + etcd 가상 IP 주소 + 네트워크 주소 변환
의존 관계 서비스가 플라넬 위에서 동작 플라넬이 없으면 같은 노드의 파드로만 연결
용어 정리

  • 플라넬 (Flannel): 쿠버네티스 클러스터의 노드들을 연결하는 IPv4 오버레이 네트워크를 구축하는 방식
  • flanneld: 모든 노드에서 구동되며 패킷 전달과 노드별 서브넷 할당을 담당하는 에이전트 프로그램
  • etcd: 쿠버네티스의 데이터 스토어. 클러스터 구성 정보를 저장함
  • 오버레이 네트워크 (Overlay Network): 기존 물리 네트워크 위에 가상으로 구성한 논리 네트워크

핵심 요약

5-1장. 컨테이너 오케스트레이션과 쿠버네티스의 기본 구조 요약:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[컨테이너 오케스트레이션]
├─ 정의: 컨테이너 관리·운영의 자동화
├─ 로드 밸런싱: 여러 컨테이너에 요청 분산 → 처리 시간 단축·처리량 증가
├─ 헬스 체크: 요청/응답으로 정상 동작 감시 → LB와 결합해 비정상 컨테이너 배제
├─ 스케일링: 메트릭 임곗값 기준으로 컨테이너 증감 → 리소스 최적화·다운 방지
└─ 수동도 가능하나 컨테이너가 늘수록 한계 → 자동화의 중요성 증가

[쿠버네티스]
├─ 구글이 개발해 오픈 소스로 공개한 오케스트레이션 도구
├─ 가능: 로드 밸런싱 · 헬스 체크 · 엔드포인트 제공
├─ 불가능: 자동 빌드 · 미들웨어 기능 (별도 도구·서비스 필요)
├─ 대안: 도커 스웜 모드 / 아파치 메소스 + 마라톤 → 그래도 쿠버네티스가 사실상 표준
└─ 클러스터 = 노드의 집합, 노드 = 마스터(제어) + 워커(파드 구동)

[파드]
├─ 컨테이너 관리의 최소 단위 (1개 이상의 컨테이너)
├─ 공유: 스토리지 · 네트워크 · (설정 시) 프로세스 네임스페이스 · 라이프 사이클
├─ 기준: 밀접한 것만 같은 파드에, 나머지는 분리 → 선택적 구동·세밀한 스케일링
├─ 필요성: 프로세스를 직접 관리하는 대신 컨테이너 관리를 쿠버네티스에 위임
└─ 패턴: 기본은 one-container-per-pod, 보조는 사이드카(Envoy, 자동화는 Istio)

[디플로이먼트 컨트롤러]
├─ 포함 관계: 디플로이먼트 > 레플리카셋 > 파드 > 컨테이너
├─ 레플리카셋: 같은 유형 파드를 지정 수만큼 유지 → 헬스 체크·스케일링·롤링 업데이트
├─ 디플로이먼트: 레플리카셋/파드 갱신을 자동화 (보통 같은 앱의 다른 버전을 포함)
├─ 컨트롤러: 현재 상태 → 설정한 상태로 조정 (에어컨 비유)
└─ 디플로이먼트 컨트롤러: 상태 감시 → 차이에 맞는 동작 결정 → 동작 실행

[서비스]
├─ 컨테이너 접속 창구(엔드포인트) 제공 — 기동/정지를 반복해도 정확히 연결
├─ 구조: 가상 IP 주소 + 네트워크 주소 변환(NAT)
├─ 유형: ClusterIP(내부) · NodePort(전 노드 포트) · LoadBalancer(외부) · ExternalName(외부 호스트)
├─ Discovery & LB: 이름 확인 + 로드 밸런싱 (ExternalName만 직접 구성 필요)
└─ 구분: 내부만 → ClusterIP, 외부 → LoadBalancer, NodePort는 예외 상황에 강점

[플라넬]
├─ 파드 내 통신: 네트워크 네임스페이스 공유 → localhost (포트 충돌 주의)
├─ 파드 간 통신: 파드마다 고유 IP → 포트 할당 방식의 복잡성·개수 제한 해소
├─ 요건: NAT 없이 모든 노드의 모든 파드와 통신 (구현 방법은 구축 시 선택)
├─ flanneld: 전 노드 에이전트 · 목적지 노드 특정 후 패킷 전송 · 노드별 서브넷 할당 · etcd 저장
└─ 서비스와의 관계: 플라넬은 기반 기술, 서비스는 그 IPv4 네트워크 위에서 동작

참고 자료

관련 자료:

네비게이션

이전 강 목록 다음 강
◀ 4-2. 컨테이너를 다루는 도구, 도커(Docker) - 파트 2 목록으로 5-2. 컨테이너 오케스트레이션 도구, 쿠버네티스 - 파트 2 ▶